This invention relates to configuring devices so that they can communicate with each other.
In many communication systems it is desirable to perform certain identification or configuration steps as part of establishing a communication link. For example two devices that require to communicate with each other may be required to authenticate each other, to ensure that they are not about to communicate with an untrusted device, and to establish security parameters that will be used for encrypting and decrypting traffic data that is subsequently transmitted between the devices.
In the Bluetooth communication system, a process known as pairing is used to help in authenticating devices to each other, and for establishing encryption parameters. The pairing process is described in sections C.4.2.2 and C.4.2.7 of version 4.0 of the Bluetooth Specification, to which the reader is referred for further details of the process. The entire contents of that specification are incorporated herein by reference.
Two pairing procedures are available in Bluetooth: standard pairing and secure simple pairing.
The standard pairing procedure between two devices A and B comprises the following three stages:
1. Each device generates a shared secret initialisation key (Kinit) based on a secret PIN. To achieve this, device A sends a random number (IN_RANDA) to device B. Then each device computes the initialisation key (Kinit) as a function (E22) of the random number (IN_RANDA), the address of device B (ADDRB), the secret PIN and the PIN length. The PIN may be entered by a user or pre-stored in one or both of the device(s).2. The devices securely exchange random numbers using the initialisation key (Kinit). To achieve this, devices A and B generate random numbers LK_RANDA and LK_RANDB respectively. Then each device XORs its own random number with the initialisation key (Kinit) and transmits the resulting value to the other device. Finally, each device recovers the random number of the other device by XORing the received value with the initialisation key (Kinit).3. Each device generates the link key (Klink) using the exchanged random numbers. To achieve this, each device generates two values, LK_KA and LK_KB. LK_KA is generated as a function (E21) of the address of device A (ADDRA) and the random number of device A (LK_RANDA). LK_KB is generated as a function (E21) of the address of device B (ADDRB) and the random number of device B (LK_RANDB). Then each device generates the link key (Klink) by bitwise modulo-2 addition of LK_KA and LK_KB.
The secure simple pairing procedure between two devices A and B comprises the following three stages.
1. Each device generates a shared secret Diffie-Hellman key (DHKey). To achieve this, each device generates a Diffie-Hellman public-private key pair. Each device then transmits the public key part of its public-private key pair to the other device. Finally, each device generates the Diffie-Hellman key (DHKey) as a function (P192) of its own private key and the other device's public key.2. Two authentication stages are performed during which the devices exchange nonces (random values) NA and NB.3. Each device generates the link key (Klink) using the Diffie-Hellman key (DHKey). Each device then generates the link key (Klink) as a function (f2) of the Diffie-Hellman key (DHKey), the nonces (NA, NB) exchanged during the authentication stages, the addresses of the devices (ADDRA, ADDRB), and a string (btlk).
The result of both pairing processes is that the devices share a link key (Klink). Klink is subsequently used as part of the algorithms for authenticating the devices to each other and for encrypting data between the devices. In the authentication algorithm, device A transmits a random number (AU_RANDA) to device B; each device computes a value which is a function (E1)) of the random number (AU_RANDA), the link key (Klink) and the address of device B (ADDRB) and device B transmits its computed value to device A. Device A then compares the response from device B with its own computed value. If the values match then the link is authenticated. In the encryption algorithm a cipherstream is generated as a function of the link key, and the cipherstream is combined with the data that is to be conveyed over the link so as to generate an encrypted data stream for transmission.
Once Klink is shared between a pair of devices, the devices can store it, normally in non-volatile memory, so that it can later be used for authentication and encryption without the pairing process having to be repeated. Once a pair of devices have jointly negotiated and stored a link key for communication with each other they are said to be paired.
After two devices have paired, Klink can be re-used as described above on a subsequent occasion. If the two devices will fulfil the same functions when they connect on the subsequent occasion then the devices will work satisfactorily. However, if one or both of the devices has changed functions when they re-connect then the devices might not be correctly configured when they re-use the stored pairing information.
One example of a situation in which this might happen is in gaming systems. Many gaming systems include a gaming console that acts as a central processor and multiple hand-held controllers that can be used by individual players. It is undesirable for a user to have to pair a hand-held controller with the gaming console each time the gaming system is turned on. For that reason, pairing information is conventionally stored by each hand-held controller so it can readily establish a link to the console at start-up. It is becoming increasingly common for each user of a gaming system to have two physically separate hand-held controllers with which they interact with the games console. A player's controllers will be referred to as X and Y. One approach by which a player's controllers can communicate with the console is for only controller X to have a communication link to the console and for controller Y to have a communication link to controller X, so that controller Y communicates with the console via the first controller. A difficulty then arises when the system is subsequently used. On that future occasion, a player might not pick up the same controllers: he might pick up two controllers that were previously being used by two different players. If the controllers re-use their stored pairing information then the player's Y controller could then be communicating with the console via another player's X controller. This is a problem because the console might interpret the player's inputs with the Y controller to be coming from that other player, and because the other player's X controller might not be in communication range of the first player's Y controller. It is possible for the controllers to be re-paired when this situation arises, but this takes time and uses energy.
There is a need for an improved mechanism of establishing communication links using pre-stored information.